Date: Wed, 24 Aug 94 04:30:19 PDT From: Ham-Digital Mailing List and Newsgroup Errors-To: Ham-Digital-Errors@UCSD.Edu Reply-To: Ham-Digital@UCSD.Edu Precedence: Bulk Subject: Ham-Digital Digest V94 #283 To: Ham-Digital Ham-Digital Digest Wed, 24 Aug 94 Volume 94 : Issue 283 Today's Topics: (none) Filters for TEKK's HF Packet MFJ 1278 - looking for software MS400 4 port serial settings? paKet6 Manual PKTMON12.LZH Will my radio work as a packet station??? (2 msgs) Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Digital Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: 23 Aug 94 14:27:00 GMT From: news-mail-gateway@ucsd.edu Subject: (none) To: ham-digital@ucsd.edu signoff ham-digital ------------------------------ Date: Mon, 22 Aug 1994 10:58:58 -0400 From: ftpbox!mothost!lmpsbbs!NewsWatcher!user@uunet.uu.net Subject: Filters for TEKK's To: ham-digital@ucsd.edu In article , jkbe@lena (John Bednar) wrote: > I am looking for suppliers that sell 21.4 Mhz IF crystal filters > that I can stuff into a TEKK data radio. I'd like to experiment > with higher data rates. Has anyone been through this before? > > John, WB3ESS > aljkbe@attme.att.com Try Piezo Technology (Technologies??) in the Ft. Lauderdale, FL area. Sorry, I don't have their phone number, but LD information for Area Code 305 should be able to find it for you. As of a few years ago they had filters for both 10.7 and 21.4 in several different bandwidths and options for sharp skirts or minimal passband ripple. At that time they were the best US supplier I could find for such goodies. -- Karl Beckman, P.E. < If our English language is so > Motorola LMPS.RNSG.Analog Data < precise, why do you drive on the > (Square waves & round corners) < parkway and park on the driveway? > Opinions expressed here do not belong to or represent Motorola Inc. Amateur radio WA8NVW NavyMARS NNN0VBH @ NOGBN.NOASI ------------------------------ Date: 23 Aug 1994 21:44:25 GMT From: newsgw.mentorg.com!wv.mentorg.com!hanko@uunet.uu.net Subject: HF Packet To: ham-digital@ucsd.edu In article , zielke@sherlock-hemlock.muppets (David Zielke) writes: |> I am in the process of examining the possibilities of using HF packet to |> provide communication between my sailboat while at sea and land based e-mail |> connections. I have been a ham since the late 70's and have been inactive |> for some time. Suggestions of what kind of gear (HF rig, TNC, computer) |> would be very helpful. I will most likely be loading the backstay as an |> antenna. Plan to use amtor, pactor, clover, gtor, or clover. Packet on HF is not actually very useful. CLOVER is best, with the other protocols working well also. |> Also, I am trying to decide between Intel based PC's and the Mac portables |> (something like a 540 active monochrome in the mac line or a 486 33mhz |> laptop in the intel world). DOS/Windows Laptop. MUCH software available for it, minimal software available for any other computer. If you end up using CLOVER, I'll see you on HF ... ... Hank -- Hank Oredson @ Mentor Graphics Library Operations Internet : hank_oredson@mentorg.com "Parts 'R Us!" Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM ------------------------------ Date: 24 Aug 94 14:55:24 GMT From: news-mail-gateway@ucsd.edu Subject: MFJ 1278 - looking for software To: ham-digital@ucsd.edu Hi and tnx reading this, I am using an tnc 1278 from MFJ for some days by controlling the exellent xp-terminal. I works well, but I would like to try some other software especially for fax and sstv too. Is there someone who can give me hint where I can find it i would be pleased. tnx in advance es 73 de Wolfgang (DL7VWH) Technische Universitaet Berlin :-% Institut fuer Bergbauwissenschaften, Sekr. BH 3 :/i Str. des 17. Juni 135, 10623 Berlin, Germany Wolfgang Heise - VOICE: ##49-30-31425672 - FAX: ..-31426797 possible on hamradio/packetradio too by DL7VWH@db0gr.bln.deu.eu ------------------------------ Date: 23 Aug 1994 00:54:30 GMT From: munnari.oz.au!yarrina.connect.com.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!news.adelaide.edu.au!mayfield@uunet.uu.net Subject: MS400 4 port serial settings? To: ham-digital@ucsd.edu Does anyone have some docco on the MS400 PC 4 port serial card, as to the dip switch settings for each port ? Ive worked a few out, but some have me bluffed, also any info on whether the card is capable of interrupt sharing ? thanks ... Rob -- rob mayfield senior technical analyst, australian submarine corporation p/l mayfield@wattle.itd.adelaide.edu.au vk5xxx@vk5xxx.#adl.#sa.aus.oc +6183487713w ------------------------------ Date: Tue, 23 Aug 1994 22:06:33 +0000 From: ihnp4.ucsd.edu!dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!emory!metro.atlanta.com!mhv.net!news.sprintlink.net!demon!g1xgp.demon.co.uk!g1xgp@@. Subject: paKet6 Manual To: ham-digital@ucsd.edu AAPRA the Australian Packet Radio Group have published a Booklet Manual of Tony Lonsdale's (VK2DHU) acclaimed paKet 6 program. AAPRA have appointed Essex Packet Shareware to acts as their UK Agent. Anyone interested in obtaining a copy/information, kindly contact the undersigned:- paket@g1xgp.demon.co.uk 73 Steve ------------------------------------------------------------------ + Steve Blinkhorn + G1XGP @ GB7WIG.#34.GBR.EU (Amateur Radio) + + AMPRnet + g1xgp@g1xgp.ampr.org [44.131.16.147] + + Essex Packet Group + g1xgp@g1xgp.demon.co.uk (Internet) + ------------------------------------------------------------------ ------------------------------ Date: Tue, 23 Aug 1994 08:45:38 From: elroy.jpl.nasa.gov!usc!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!sislnews.csc.ti.com!ken_durham.linear.sc.ti.com!ken@ames.arpa Subject: PKTMON12.LZH To: ham-digital@ucsd.edu PKTMON12 is supposedly a program to allow reception of packet radio signals without an external TNC or multimode controller. It gets its input from the radio speaker output through an op-amp attached to the PC serial port. The signal is decoded and displayed on the Hamcom program terminal screen. Both programs are shareware, but PKTMON12 was hard to find. I finally got it by ftp from funet.fi. The problem is that the program is compressed and has a suffix of LZH. If anyone can tell me where to obtain a copy of whatever decompression program is required for LZH, I would appreciate it. de K5MBV PS. My email should be working now. ------------------------------ Date: 23 Aug 1994 10:06:09 -0400 From: newstf01.cr1.aol.com!search01.news.aol.com!not-for-mail@uunet.uu.net Subject: Will my radio work as a packet station??? To: ham-digital@ucsd.edu I have a Baycom modem that I got from A&A engineering. I wish to hook it up to one of my radios to run packet but I have heard that some radios do not switch fast enough from transmit to receive? My possible radios are: Azden PCS-3000 Yaesu FT-207R Icom 02-AT Standard SR-C146A Will any of these radios work without modification? If not, can they be modified to work? Please e-mail JoeSullivn@AOL.com ------------------------------ Date: Tue, 23 Aug 1994 21:45:59 GMT From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!news.cac.psu.edu!ppp35.cac.psu.edu!cwm3@network.ucsd.edu Subject: Will my radio work as a packet station??? To: ham-digital@ucsd.edu In article <33cvoh$3n4@search01.news.aol.com> joesullivn@aol.com (JoeSullivn) writes: >From: joesullivn@aol.com (JoeSullivn) >Subject: Will my radio work as a packet station??? >Date: 23 Aug 1994 10:06:09 -0400 >I have a Baycom modem that I got from A&A engineering. I wish to hook it >up to one of my radios to run packet but I have heard that some radios do >not switch fast enough from transmit to receive? My possible radios are: >Azden PCS-3000 >Yaesu FT-207R >Icom 02-AT >Standard SR-C146A >Will any of these radios work without modification? >If not, can they be modified to work? >Please e-mail JoeSullivn@AOL.com Hi Joe. I am sure the Azden, Yaesu, and Icom will work just fine. In fact, I sometimes use my IC-02AT on packet. I'm not sure about the Standard but don't think it would have any problem. In general, any rig will work but those with solid-state T/R switching are preferred. Some rigs may require some adjustments to certain TNC parameters but that turns out to be no big deal. 73, Chuck - K3CM ------------------------------ Date: Tue, 23 Aug 1994 16:48:17 GMT From: world!dts@uunet.uu.net To: ham-digital@ucsd.edu References <32d90d$2gg@vixen.cso.ui, <3306v8$jbi@vixen.cso.uiuc.edu>, <1994Aug20.143652.9960@ke4zv.atl.ga.us> Subject : Re: Looking for DXCluster software In article <1994Aug20.143652.9960@ke4zv.atl.ga.us>, Gary Coffman wrote: >In article <3306v8$jbi@vixen.cso.uiuc.edu> k9cw@prairienet.org (Andrew B. White) writes: >>While I agree with you that PC use of AX.25 is not the best for distributing >>spots, it is, currently, the only game in town. > >Note that broadcast servers us AX.25 too, just UI frames instead of >connected mode frames. The FCC has us locked into AX.25 wrappers for >unattended third party use. > >>AK1A has something like >>400 nodes installed around the world, and they all talk to each other (altho >>the email facility comes close to being useless if the mail has to go more >>than one hop). Besides, if the network is configured as it should be, >>with local users on one frequency and the inter-node link on another, I >>am not sure that the amount of bandwidth required is an issue. > >While splitting the users off the backbone is essential to making the >systems work well at all, it *does* increase the amount of bandwidth >the systems tie up. The real problem is that connected mode bulletin >distribution uses nearly 26 times the channel capacity of a broadcast >server. That means in practice, at our current low channel speeds, that >channels have to be *dedicated* to Packet Cluster activity rather than >being timeshared with other packet uses. That's bad spectrum utilization. > >Of course faster channel speeds can help, and I note with approval >that Packet Clusters seem to be among the first to embrace faster >channel speeds (out of necessity), first jumping to 2400 baud and >now going to 9600 baud. But that's only a less than 2 and less than >9 increase in channel capacity respectively at best (actually much >worse than that on a simplex frequency due to turnaround and overhead >delays). But a simple change to a broadcast protocol would *immediately* >give a nearly 26 fold increase in available channel capacity. Since it's >*only software* (heh), the change could be relatively quick and painless >too. > >Note, broadcast use would free up channels only by allowing more >than 26 stations per cluster. The channel would still have to be >dedicated to the broadcast server. But the server could also serve >more than just DX spots with the excess channel capacity. It could >also distribute other types of bulletins and files in it's idle >time. > >I don't think most connected mode servers are a good use of packet >resources any longer. Broadcast servers are so much more efficient >that Cluster *and* BBSs should change over as rapidly as practical. >There remain some cases where connected mode works best, like serving >low density WANs that need digis to get coverage. For higher density >areas, however, the broadcast server is very much superior for most >uses. (Personal Email may remain an exception.) Perhaps we need to >think about making broadcast the bulletin and file distribution default, >and connected mode the exception, in future server designs. Gary, I assume then that you favor the discontinuance of using TELNET and FTP on top of TCP/IP in favor of a broadcast or multicast equivalent? The big problem I see with "simply" replacing the use of connection- oriented packets with UI frames for DX clusters is one of reliability. Packet is an extremely UNRELIABLE data link. That has to be factored in to any change which is made. There's nothing wrong with running over unreliable media, you just have to account for that in higher level protocols. At some point in the stack you must acknowledge frames, or recognize (in the broadcast case) that you've missed frames, and ask for repeats. How is the PacketCluster machine to know that the UI frame with a DX spot just got stomped by another station starting to transmit a frame? Packet radio does NOT run with Collision Detection in the way that Ethernet does. You cannot tell, when transmitting, that your frame has just gotten munched. Dan -- --------------------------------------------------------------- Daniel Senie Internet: dts@world.std.com Daniel Senie Consulting n1jeb@world.std.com 508-779-0439 Compuserve: 74176,1347 ------------------------------ Date: 23 Aug 1994 01:31:09 GMT From: agate!howland.reston.ans.net!vixen.cso.uiuc.edu!prairienet.org!k9cw@ames.arpa To: ham-digital@ucsd.edu References <1994Aug18.144706.28341@ke4zv.atl.ga.us>, <119955@cup.portal.com>, <32b56i$ot5@T Reply-To : k9cw@prairienet.org (Andrew B. White) Subject : Re: Looking for DXCluster software In a previous article, gary@ke4zv.atl.ga.us (Gary Coffman) says: >While splitting the users off the backbone is essential to making the >systems work well at all, it *does* increase the amount of bandwidth >the systems tie up. But if we move these users to another band (222/440/900 or whatever) we can re-use the bandwidth, and accommodate the current users given current equipment. I am confused about how the broadcast server works. Does each end-point periodically transmit a poll to see if any messages were missed? Or is the assumption made that every end-point receives every broadcast error free? With UI frames, does each end-point "guess" whether the broadcast was from the broadcast server base on what can be recovered from a corrupted frame? Does the broadcast server continuously repeat the last N spots? PacketCluster presently provides more than just spot information, but the DX spots are the most important. Without the ability for each end-point to confirm receipt or request fills, it seems to me we have no better a system than the old 2m voice net (actually not quite that bad) or the 2m Baudot net we used to use in the 70's. If fill requests do not occur on the broadcast frequency, then we need a second channel for email transmission, listing old DX spots, searching the callbook, etc. How would that work with the broadcast server? 73, Drew -- *-----------------------------*-------------------------------------* | Andrew B. White K9CW | internet: k9cw@prairienet.org | | ABW Associates, Ltd. | phone/fax: 217-643-7327 | *-----------------------------*-------------------------------------* ------------------------------ Date: Mon, 22 Aug 1994 10:38:16 -0400 From: ftpbox!mothost!lmpsbbs!NewsWatcher!user@uunet.uu.net To: ham-digital@ucsd.edu References <32d90d$2gg@vixen.cso.ui, <3306v8$jbi@vixen.cso.uiuc.edu>, <1994Aug18.200851.17094@nosc.mil> Subject : Re: Looking for DXCluster software In article <1994Aug18.200851.17094@nosc.mil>, craigr@n6nd.nosc.mil wrote: > In <3306v8$jbi@vixen.cso.uiuc.edu>, k9cw@prairienet.org (Andrew B. White) writes: > > > >In a previous article, gary@ke4zv.atl.ga.us (Gary Coffman) says: > > > >>Yes, $400 is excessive. It's excessive because cluster is such a bandwidth > >>wasting kludge. (Ok, it's a *useful* kludge, but kludge it is.) You can > >>use free broadcast server software sending the info *2* times, one uplink > >>and one broadcast (Pacsat protocol), instead of *27* to accomplish the > >>same DX spot reporting. That's much more bandwidth friendly. Fills can be > > > >While I agree with you that PC use of AX.25 is not the best for distributing > >spots, it is, currently, the only game in town. AK1A has something like > >400 nodes installed around the world, and they all talk to each other (altho > >the email facility comes close to being useless if the mail has to go more > >than one hop). Besides, if the network is configured as it should be, > >with local users on one frequency and the inter-node link on another, I > >am not sure that the amount of bandwidth required is an issue. > > I also agree that AX.25 is not the best protocol for sending DX spots but > PacketCluster is an AX.25 application that requires the minimum equipment > on the user end. A radio, TNC, and dumb terminal is the user investment. It > would seem that to implement a more efficient protocol would certainly require > a computer on the user end to sort things out. Some of the OF's barely mastered > getting a dumb terminal to talk to a TNC, it would be real interesting watching > them trying to become computer literate. Hi.. > > But if someone came out with a system that offered enough advantages over the > current Cluster software, I think it might catch on. There are many problems > with PC that could be overcome by a more robust protocol which would be very > attractive to the sysops. My own feeling is that PacketCluster needs competition > or many of the problems with it are not going to be solved. > > Rick Craig, N6ND > craigr@marlin.nosc.mil Well, I'm no software writer or DX Cluster user, but I'm still a ham and we all offer opinions, solicited or otherwise. I'm NOT offering to write this update or even beta-test it, but let me toss one suggestion onto the pile: 1) Take a look at the APRS software by Bob Bruninga WB4APR and note how he uses the beacon message to communicate location data without requiring "ack"s from every recipient. 2) Apply the same idea to Packet Cluster, possibly fitting in some other improvements at the same time such as the APRS location. This would soothe Gary's very legitimate distress about packet channel loading. Any station beaconing in the proper format could be "logged in" to P-C if their APRS coordinates were within a reasonable distance of the P-C host area. Full 2-way connects would not be required unless the operator needed the FULL P-C BBS services; persons wanting only the DX spots could simply watch the beacons go by. In fact, that's what I do most of the time to avoid loading the PacketCluster frequency with unneeded acks, but it is frustrating to watch the same spot go by 64 times when P-C is fully occupied. 3) If someone can convince K1EA and WB4APR to work together, I'll bet that each of them can find at least one more way to improve the combined software and two more applications that we haven't yet thought of. Synergy, cooperation, and talent arte a combination that is almost impossible to beat (unless your name is Bill Gates, anyhow!). -- Karl Beckman, P.E. < If our English language is so > Motorola LMPS.RNSG.Analog Data < precise, why do you drive on the > (Square waves & round corners) < parkway and park on the driveway? > Opinions expressed here do not belong to or represent Motorola Inc. Amateur radio WA8NVW NavyMARS NNN0VBH @ NOGBN.NOASI ------------------------------ End of Ham-Digital Digest V94 #283 ******************************